Each USB device contains one or more endpoints, which are the fundamental communication channels used to exchange data with the host. An endpoint is identified by its number, direction, and transfer type — together these form the basis of the device's programming interface.

Maximum Number of Endpoints

A USB device can support up to 32 logical endpoints:

• Endpoint 0 (EP0) is mandatory for every device — see Control Endpoints.
• The remaining endpoints are optional and depend on the device's class and function.

Endpoint Addressing

Each endpoint is uniquely identified by a combination of:

This is encoded in the bEndpointAddress field of the Endpoint Descriptor.

Example

Endpoint Direction

IN Endpoint

• Sends data from the device to the host
• The device loads data into its IN endpoint buffer
• The host retrieves the data by issuing an IN token

OUT Endpoint

• Receives data from the host to the device
• The host sends data with an OUT token
• The device stores the data in its OUT endpoint buffer

Bidirectional Communication

To support two-way data transfer, a device implements a matched pair:

Host ── OUT ──► Endpoint 1 OUT buffer (device receives)
Host ◄── IN ── Endpoint 1 IN buffer  (device sends)

These are separate endpoints with separate buffers, even though they share endpoint number 1.

Endpoint Buffers

Each endpoint must include a buffer capable of storing at least one full-size USB packet.

The required buffer size is defined by the wMaxPacketSize field in the Endpoint Descriptor.

Maximum Packet Sizes by Speed and Transfer Type

Double Buffering

Some device implementations use double buffering (ping-pong buffers):

• While the host reads from one buffer, the device fills the other
• Improves throughput by overlapping data transfer and processing
• Common in high-throughput endpoints (bulk, isochronous)

Why Buffers Are Needed

USB is a host-scheduled bus — the device cannot initiate transfers on its own. Buffers bridge the timing gap:

• OUT direction: The host may send data before the device firmware is ready to process it — the buffer holds incoming data
• IN direction: The device firmware prepares data in advance — the buffer holds it until the host polls
• Speed mismatch: The USB bus operates at fixed frame intervals (1 ms for FS, 125 µs for HS) while device processing time varies

Without buffers, data would be lost whenever the bus and device firmware are not perfectly synchronized.

Endpoints as the Device Programming Interface

The complete set of endpoints defines how software communicates with the device:

┌──────────────────────────────────────────────┐
│              Host Software                   │
│  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐      │
│  │Pipe 0│  │Pipe 1│  │Pipe 2│  │Pipe 3│      │
│  └──┬───┘  └──┬───┘  └──┬───┘  └──┬───┘      │
└─────┼─────────┼────────┼─────────┼───────────┘
      │         │        │         │   USB Bus
┌─────┼─────────┼────────┼─────────┼───────────┐
│  ┌──▼───┐  ┌──▼───┐  ┌▼─────┐  ┌▼─────┐      │
│  │ EP0  │  │EP1 IN│  │EP1OUT│  │EP2 IN│      │
│  │(Ctrl)│  │(Bulk)│  │(Bulk)│  │(Intr)│      │
│  └──────┘  └──────┘  └──────┘  └──────┘      │
│              USB Device                      │
└──────────────────────────────────────────────┘

Each pipe maps a host-side memory buffer to a device endpoint. Drivers interact with pipes to send commands, read status, and transfer data.

Example: USB Mass Storage Device

A typical mass storage device uses three endpoints:

Data Flow (SCSI Read)

Host  ── Bulk OUT ──►  Device    (Command Block Wrapper: SCSI READ)
Host  ◄── Bulk IN ──   Device    (Requested data sectors)
Host  ◄── Bulk IN ──   Device    (Command Status Wrapper: success/fail)

Example: USB Keyboard